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Abstract 


Modern  society  could  hardly  function  without  the  large-scale,  network-centric  information 
systems  that  pervade  government,  defense,  and  industry.  As  a  result,  serious  failures  or  com¬ 
promises  carry  far-reaching  consequences.  These  systems  are  characterized  by  changing  and 
often  unknown  boundaries  and  components,  constantly  varying  function  and  usage,  and 
complexities  of  pervasive  asynchronous  operations.  Their  complexity  challenges  human  in¬ 
tellectual  control,  and  their  survivability  has  become  an  urgent  priority.  Engineering  methods 
based  on  solid  foundations  and  the  realities  of  network  systems  are  required  to  manage  com¬ 
plexity  and  ensure  survivability.  Flow-Service-Quality  (FSQ)  engineering  is  an  emerging 
technology  for  management,  acquisition,  analysis,  development,  evolution,  and  operation  of 
large-scale,  network-centric  systems.  FSQ  engineering  is  based  on  Flow  Structures,  Compu¬ 
tational  Quality  Attributes,  and  Flow  Management  Architectures.  These  technologies  can 
help  provide  stable  engineering  foundations  for  the  dynamic  and  often  unpredictable  world  of 
large-scale,  network-centric  systems.  Flow  Structures  define  enterprise  mission  task  flows 
and  their  refinements  into  uses  of  system  services  in  network  traversals.  Flows  are  determi¬ 
nistic  for  human  understanding,  despite  the  underlying  asynchronism  of  network  operations. 
They  can  be  refined,  abstracted,  and  verified  with  precision,  and  deal  explicitly  with  Uncer¬ 
tainty  Factors,  including  uncertain  commercial  off-the-shelf  functionality  and  system  failures 
and  compromises.  Computational  Quality  Attributes  go  beyond  static,  a  priori  estimates  to 
treat  quality  attributes  such  as  reliability  and  survivability  as  dynamic  functions  to  be  com¬ 
puted  in  system  operation.  Computational  Quality  Attribute  requirements  are  associated  with 
flows  and  can  be  dynamically  reconciled  with  network  service  attributes  in  execution.  Flow 
Management  Architectures  include  design  and  implementation  frameworks  for  dynamically 
managing  flows  and  attribute  requirements,  as  well  as  processes  for  their  development.  FSQ 
foundations  are  defined  by  theorems  that  illuminate  engineering  practices  and  automation 
opportunities. 
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1  Network  System  Realities 


Modem  enterprises  are  irreversibly  dependent  on  large-scale  network  systems  whose  com¬ 
plexity  frequently  exceeds  current  engineering  capabilities  for  intellectual  control.  The  result 
has  been  persistent  difficulties  in  development,  management,  and  evolution,  and  failures,  in¬ 
trusions,  and  compromises  in  operation  [Schneider  1999].  These  systems  are  characterized 
by  very-large-scale  heterogeneous  networks  with  often-unknown  boundaries  and  compo¬ 
nents.  Dynamic  interconnectivity  of  systems-of-systems  can  limit  visibility  and  control  of 
security  and  survivability.  User  task  flows  can  traverse  systems  and  boundaries  with  varying 
security  and  survivability  characteristics.  In  addition,  these  systems  must  deal  with  uncertain 
commercial  off-the-shelf  (COTS)  function  and  quality,  unforeseen  behaviors  and  vulnerabili¬ 
ties,  and  unanticipated  inter-system  cascade  failures.  Complexity  is  compounded  by  the  ex¬ 
tensive  asynchronous  behavior  of  the  virtually  unknowable  interleaving  of  communications 
among  system  components.  Figure  1  depicts  components  of  such  a  network-centric  system, 
the  Future  Combat  System  (FCS),  where  each  component  is  a  complex  system  in  its  own 
right. 
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Figure  1:  Elements  of  the  Network-Centric  Future  Combat  System 
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The  FCS  is  highly  distributed,  contains  hundreds  of  nodes,  is  operated  by  thousands  of  users, 
conducts  complex  asynchronous  communications  and  operations,  is  subject  to  damage,  dis¬ 
ruption,  and  compromise,  and  undergoes  continual  upgrade  and  evolution.  Controlling  com¬ 
plexity  and  ensuring  survivability  are  priorities  for  the  development  of  systems  such  as  FCS. 


Similar  characteristics  are  found  in  commercial  network-centric  systems.  Consider  the  sys- 
tem-of-systems  traversals  involved  in  a  gasoline  purchase  transaction  with  a  credit  card  de¬ 
picted  in  Figure  2.  Hundreds  of  hardware  and  software  components  are  traversed  through 
many  systems  in  the  multiple  conversations  from  gas  pump  to  landline  and  satellite  telecom¬ 
munications  to  credit  database  and  back,  with  many  outcomes  possible.  Each  system  in¬ 
volved  in  the  network  exhibits  unique  functionality  and  quality  attributes,  including  reliabil¬ 
ity,  security,  and  survivability. 
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Figure  2:  System-of-Systems  Traversals  in  a  Gasoline  Purchase  Transaction 

The  burden  of  unmastered  complexity  creates  difficulties  in  understanding  systems  we  have 
and  in  defining  systems  we  need.  It  leads  to  loss  of  intellectual  control  when  it  exceeds  hu¬ 
man  capabilities  for  reasoning  and  analysis.  Intellectual  control  means  understanding  system 
behavior  at  all  levels  in  all  circumstances  of  use.  It  means  orderly  development  and  evolu¬ 
tion,  and  no  surprises  in  operation.  Intellectual  control  does  not  mean  the  absence  of  uncer¬ 
tainty,  failures,  or  compromises — they  are  inevitable — but  rather  the  foresight  and  capability 
to  deal  with  them.  And  it  does  not  require  slow  and  burdensome  methods  for  development. 
On  the  contrary,  intellectual  control  enables  rapid  development  with  confidence.  Without 
intellectual  control,  guessing  and  hoping  are  the  order  of  the  day,  and  surprises  are  inevitable. 


Complexity  barriers  can  be  swept  away  by  the  right  foundations.  When  the  Normans  con¬ 
quered  England  in  the  1 1th  century,  they  conducted  a  census  to  determine  what  had  been  had 
won.  But  the  results  were  never  added  up,  despite  the  obvious  interest  in  such  a  sum.  The 
census  data  had  been  recorded  in  the  Roman  system,  and  the  best  minds  of  the  day  were 
overwhelmed  by  the  complexity  of  adding  up  so  many  Roman  numbers.  The  representation 
and  reasoning  methods  were  themselves  a  primary  source  of  complexity.  But  if  the  census 
had  been  recorded  in  decimal  arithmetic  with  place  notation,  any  child  of  the  realm  could 
have  produced  the  necessary  sums.  The  right  foundations  would  have  made  all  the  differ¬ 
ence. 
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Today,  we  face  complexity  and  survivability  issues  on  a  whole  new  level  in  large-scale  net¬ 
work  systems.  Complexity  reduction  requires  solid  foundations  and  engineering  methods  to 
maintain  intellectual  control  in  specification,  design,  and  operation.  Complexity  and  surviv¬ 
ability  are  closely  related.  Complexity  diminishes  survivability  by  masking  potential  failures 
and  vulnerabilities,  and  hiding  unforeseen  access  paths  for  intrusion.  Survivability  improve¬ 
ment  requires  knowing  system  component  dependencies  in  all  usage  situations,  preparing  for 
component  compromises  and  failures  in  all  situations,  and  designing  system  actions  for  all 
situations  [Ellison  et  al.  1999c,  Mead  et  al.  2000].  In  short,  survivability  requires  intellectual 
control. 


This  paper  describes  the  emerging  Flow-Service-Quality  (FSQ)  engineering  process  that  pro¬ 
vides  foundations  and  methods  for  dealing  with  complexity  and  survivability  in  network¬ 
centric  systems.  Section  2  provides  an  overview  of  FSQ  technologies.  Section  3  discusses 
semantic  foundations  of  Flow  Structures,  and  Section  4  provides  illustrations  of  Flow  Struc¬ 
ture  engineering  operations.  Section  5  introduces  Computational  Quality  Attributes,  and  Sec¬ 
tion  6  discusses  Flow  Management  Architectures.  Section  7  summarizes  the  contributions 
and  implications  of  FSQ  research.  Future  papers  will  describe  mathematical  foundations  for 
Flow  Structures  and  Computational  Quality  Attributes,  and  introduce  engineering  practices 
for  their  application. 
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2  Flow-Service-Quality  Engineering 


Development  of  large-scale  network  systems  is  essentially  a  massive  integration  activity  that 
seeks  to  reconcile  and  satisfy  user  requirements  through  combinations  of  COTS  and  unique 
components,  often  within  a  framework  of  predefined  environments,  legacy  systems,  enabling 
technologies,  and  domain  architectures.  A  key  issue  in  modern  system  development  is  how  to 
maintain  intellectual  control  over  such  complex  structures  and  the  asynchronous  behaviors 
they  produce.  In  this  world  of  large-scale,  asynchronous  network  systems  with  dynamic  and 
often  uncertain  functionality  and  structure,  we  ask  three  questions  that  deal  with  engineering 
methods  for  complexity  reduction  and  survivability  improvement: 

1 .  What  are  the  unifying  engineering  foundations  for  system  analysis,  specification,  design, 
and  verification? 

2.  How  should  quality  attributes  such  as  survivability,  reliability,  and  performance  be 
specified  and  achieved? 

3.  What  architecture  frameworks  can  simplify  system  development  and  operation? 

In  short,  what  are  the  stable  and  dependable  anchors  for  specification  and  design  that  can 
provide  a  unified  engineering  discipline  for  large-scale  network  system  analysis  and  devel¬ 
opment?  Our  research  is  developing  new  approaches  to  answer  these  questions.  The  follow¬ 
ing  concepts  help  to  structure  our  research  thinking: 

1 .  Flow  Structures 

User  task  flows  and  their  refinements  into  system  service  uses  can  provide  unifying  en¬ 
gineering  foundations  for  analysis,  specification,  design,  and  verification  of  functionality 
and  quality  attributes. 

2.  Computational  Quality  Attributes 

Quality  attributes  can  be  associated  with  both  flows  and  the  system  services  they  invoke, 
and  specified  as  dynamic  functional  properties  to  be  computed,  rather  than  as  static,  a 
priori  predictions  of  uncertain  utility  in  real-time  system  operations. 

3.  Flow  Management  Architectures 

Flow  Structures  and  Computational  Quality  Attributes  support  canonical  architecture 
frameworks  that  manage  flows,  network  services,  and  their  quality  attributes  in  execu¬ 
tion. 

Flow  Structures  are  compositions  of  system  services  that  carry  out  user  tasks  to  accomplish 
enterprise  missions.  They  employ  unique  semantics  to  preserve  important  deterministic 
properties  for  precise  human  understanding  and  analysis,  despite  the  underlying  asynchro- 
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nism  and  unpredictability  of  network  behavior.  Flow  Structures  take  into  account  unpredict¬ 
able  events  and  outcomes  that  can  impact  mission  survivability.  Computational  Quality  At¬ 
tributes  of  flows  and  the  services  they  invoke  can  be  dynamically  managed  in  execution. 
Thus,  the  first-class  concepts  of  flow,  service,  and  quality  form  the  basis  for  the  emerging 
discipline  of  Flow-Service-Quality  (FSQ)  engineering  [Hevner  et  al.  2001,  Hevner  et  al. 
2002],  A  persistent  problem  in  development  and  management  of  large-scale  network-centric 
systems  has  been  the  lack  of  unified,  scale -free  engineering  foundations  for  intellectual  con¬ 
trol  in  management,  acquisition,  analysis,  development,  evolution,  and  operation.  FSQ  engi¬ 
neering  addresses  that  problem  through  theoretical  foundations  and  practical  engineering 
methods  to  represent,  analyze,  develop,  and  dynamically  manage  system  flows  and  their 
quality  attributes  as  essential  and  primary  artifacts  of  network  system  development. 


Distributed  information  systems  are  usefully  viewed  as  networks  of  asynchronously  commu¬ 
nicating  components  that  provide  system  services  whose  functions  can  be  combined  in  vari¬ 
ous  patterns  to  satisfy  enterprise  mission  requirements.  System  services  include  all  the  func¬ 
tional  capabilities  of  a  network  system,  from  communication  protocols  and  operating  systems 
to  databases  and  applications.  The  sequencing  of  system  services  in  user  task  flows  can  be 
mapped  into  compositions  of  network  hardware,  software,  and  human  components  that  pro¬ 
vide  the  services.  These  compositions  are  end-to-end  traces  that  define  slices  of  network  ar¬ 
chitectures  whose  net  effect  is  to  carry  out  operations  that  satisfy  user  requirements.  Figure  3 
depicts  refinement  of  user  task  flows  based  on  mission  objectives  into  uses  of  system  archi¬ 
tecture  components. 


Enterprise: 


Enterprise  mission 


An  enterprise  mission  is  embodied 
in  user  task  flows  of  operations  and 
decisions  in  system  usage 


Users: 

<^> 
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Architecture  flow  refinements  of  user  task  flows  are 
conditional  compositions  of  system  services  that 
provide  functionality  and  quality  attributes 


User  task  flow 


User  task  flow 
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Architecture  flow 
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Figure  3:  Refinement  into  User  Task  Flows  into  System  Service  Uses 

Large-scale  systems  support  many  simultaneous  users  in  many  roles  with  many  possible  task 
flows,  and  particular  system  services  may  appear  over  and  over  in  their  definitions.  In  fact,  a 
principal  design  objective  in  large-scale  systems  is  coordination  and  synchronization  of  mul¬ 
tiple  uses  of  particular  services  incorporated  into  flows.  In  dynamic  networks  with  constantly 
varying  function  and  usage,  flows  and  their  corresponding  architecture  traces  of  system  ser¬ 
vices  [Parnas  and  Wang  1994]  act  as  stable  foundations  for  functional  and  non-functional, 
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that  is,  quality  attribute,  specification  and  design.  In  execution,  services  invoked  by  flows 
can  experience  a  blizzard  of  asynchronous  usage  interleavings  that  defies  human  understand¬ 
ing.  A  key  property  of  Flow  Structures  is  a  semantic  foundation  that  permits  flows  to  exhibit 
deterministic  properties  for  straightforward  human  understanding  and  analysis,  despite  the 
underlying  asynchronous  behavior.  Thus,  flows  can  be  represented  as  simple  procedural 
structures  composed  of  nested  and  sequenced  service  invocations  and  local  computations  ex¬ 
pressed  in  terms  of  ordinary  sequence,  alternation,  iteration,  and  concurrent  structures.  Such 
structures  define  an  algebra  of  component  composition  with  desirable  properties.  For  exam¬ 
ple,  Flow  Structures  preserve  effective  reasoning  methods  of  composition  and  referentially 
transparent  refinement,  abstraction,  and  verification  for  human  understanding.  Flows  can  be 
expressed  in  virtually  any  language  using  Flow  Structure  primitives  to  specify  user  task  uses 
of  system  services  in  precise  terms.  Services  invoked  by  flows  can  be  refined  into  flows  in¬ 
voking  other  services,  etc.,  in  a  recursive  design  process  that  employs  identical  structures  and 
engineering  methods  at  all  levels  of  refinement.  Flow  Structures  are  superficially  related  to 
workflow  methods  [Leymann  and  Roller  2000],  but  define  rigorous  scale-free  foundations  for 
large-scale  system  analysis,  development,  and  operation. 


Flows  can  be  organized  into  related  FlowSets  associated  with  particular  components  and 
network  partitions.  Transitivity  analysis  of  flows  can  reveal  often-unforeseen  dependencies. 
Flows  define  required  levels  of  quality  attributes  for  themselves,  as  well  as  for  execution  of 
the  services  they  reference.  FSQ  engineering  operations  for  existing  and  new  systems  are  de¬ 
picted  in  Figure  4.  For  new  systems,  flow  specification  begins  with  user  tasks  that  support 
enterprise  mission  objectives,  thereby  ensuring  a  user-centric  approach  to  design  and  devel¬ 
opment.  In  particular,  flows  are  vehicles  for  definition  of  required  quality  attributes,  such  as 
reliability  and  survivability.  Some  flows  require  higher  levels  of  reliability  and  survivability 
than  others,  and  flow-specific  definition  of  attribute  requirements  permits  informed 
cost/benefit  tradeoffs  in  system  design.  For  existing  systems,  flows  of  mission-critical  opera¬ 
tions  can  be  extracted  and  analyzed  to  reveal  unforeseen  dependencies  and  single  points  of 
failure.  Such  analysis  permits  identification  and  development  of  survivability  improvements. 
It  is  important  to  note  that  flows  can  define  both  legitimate  and  illegitimate  use.  Intruder  us¬ 
age  of  systems  can  be  expressed  in  flows  to  reveal  compromisable  components  and  help  de¬ 
fine  security  and  survivability  improvements  [Mead  et  al.  2000,  Moore  et  al.  2001], 
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Figure  4:  FSQ  Engineering  Operations  for  New  and  Existing  Systems 

In  terms  of  intuitive  understanding,  flows  can  be  thought  of  as  deterministic  hierarchies  of 
service  uses  superimposed  for  execution  with  other  flows  on  a  large-scale  asynchronous  net¬ 
work.  This  concept  is  depicted  in  Figure  5  for  a  flow  in  the  Future  Combat  System  example. 
Flows  define  a  structured  use  of  network  capabilities  through  definition  of  communications 
among,  and  compositions  of,  network  system  services. 


Figure  5:  Superimposing  a  Deterministic  Flow  on  an  Asynchronous  Network 

In  FSQ  engineering,  quality  attributes  such  as  availability,  reliability,  and  survivability  are 
defined  as  computational  functions,  and  are  associated  with  both  flows  and  services.  Substan- 
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tial  effort  has  been  devoted  in  the  past  to  development  of  a  priori  characterizations  of  quality 
attributes.  Rather  than  focusing  on  descriptive  methods  of  limited  value  for  dynamic  net¬ 
works,  we  adopt  an  alternate  approach  and  ask  how  such  attributes  can  be  defined,  computed, 
and  acted  upon  as  dynamic  characteristics  of  system  operation.  That  is,  we  wish  to  define 
quality  attributes  as  functions  to  be  computed,  rather  than  as  static  descriptions  of  capabilities 
to  be  achieved.  While  such  functions  rely  on  what  can  be  computed  and  may  differ  thereby 
from  traditional  views  of  quality  attributes,  they  can  permit  new  approaches  to  attribute 
analysis,  design,  metrics,  and  operational  evaluation.  A  key  aspect  of  the  computational  ap¬ 
proach  is  the  ability  to  associate  quality  attributes  with  specific  flows  rather  than  with  entire 
systems,  thereby  permitting  differentiation  among  attribute  capabilities  based  on  mission 
criticality  in  survivability  engineering.  Some  quality  attributes,  such  as  availability  and  reli¬ 
ability,  are  readily  quantified  for  computational  analysis.  Others,  such  as  security  and  surviv¬ 
ability  will  be  more  difficult.  Nevertheless,  we  believe  the  effort  must  be  made,  and  that  new 
approaches  and  insights  will  result. 


In  a  world  of  Flow  Structures  and  Computational  Quality  Attributes,  it  is  natural  to  consider 
system  architecture  frameworks  based  on  dynamic  flow  and  quality  attribute  management 
[Sikora  and  Shaw  1998,  Haeckel  1999,  Sullivan  et  al.  1999].  A  primary  control  task  in  large- 
scale  systems  is  managing  the  sequencing  of  system  services  in  real  time  to  satisfy  flow 
specifications.  FSQ  concepts  suggest  standard,  subject-matter-independent  Flow  Manage¬ 
ment  Architecture  (FMA)  frameworks  for  dynamic  flow  and  attribute  management  in  execu¬ 
tion.  Such  frameworks  could  reconcile  flow  requirements  with  service  availabilities,  and  im¬ 
plement  operational  management  strategies  based  on  dynamic  network  and  service 
capabilities  and  workloads.  FMA  frameworks  embody  the  concept  of  an  FSQ  Manager,  cen¬ 
tralized  or  decentralized  within  the  architecture  of  a  system,  which  provides  such  flow  man¬ 
agement.  In  particular,  an  FSQ  Manager  could  provide  dynamic  quality  attribute  evaluation. 
For  example,  survivability  management  could  include  a  variety  of  strategies  such  as  rerouted 
communication  paths,  resource  substitutions,  state  reconstruction,  alternate  provisioning,  and 
system  reinitialization  and  reconfiguration.  An  FSQ  Manager  could  be  designed  and  instan¬ 
tiated  in  a  variety  of  forms  and  technologies,  depending  on  user  requirements,  network  con¬ 
figuration,  and  the  operational  environment. 


FSQ  engineering  can  reduce  complexity  and  add  clarity  to  network  system  development. 

Flow  Structure  specifications  of  enterprise  tasks  can  be  designed  and  verified  with  full  human 
understanding  at  various  levels  of  abstraction  in  a  seamless  process  from  user  task  flows 
down  to  architecture  components.  Flow  Structures  prescribe  logical  network  connections  and 
operations,  define  compositionality  among  nodes  and  services,  and  support  both  centralized 
and  distributed  control.  The  specification  of  network  system  behavior  and  logical  connec¬ 
tivity  is  defined  by  the  set  of  flows  of  its  service  uses.  The  specification  of  each  service  in  a 
network  system  incorporates  all  its  uses  in  all  the  flows  in  which  it  appears.  Flow  Manage¬ 
ment  Architecture  frameworks  provide  systematic  templates  for  managing  flow  instantiations 
and  reconciling  Computational  Quality  Attributes. 
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3  Flow  Structure  Semantics 


3.1  The  Semantic  Model 

In  large-scale  network  systems,  flows  can  engage  in  extensive  traversals  of  network  nodes 
and  communication  links,  where  the  behavior  of  invoked  services  cannot  always  be  known 
and  predicted.  In  this  environment  a  variety  of  Uncertainty  Factors  must  be  managed,  includ¬ 
ing: 

1 .  Unpredictable  function 

A  service  may  be  provided  by  COTS  or  External  Service  Provider  (ESP)  components  of 
unpredictable  function  and  reliability  that  may  not  perform  expected  operations  every 
time  or  any  time  it  is  invoked. 

2.  Compromised  function 

A  service  may  have  been  compromised  or  disrupted  by  an  intrusion  or  physical  attack 
and  may  not  be  able  to  perform  its  function  correctly  or  at  all. 

3.  High-risk  function 

A  service  may  not  provide  adequate  levels  of  quality  attributes  (Quality  of  Service) 
required  by  a  flow. 

4.  Modified  function 

A  service  may  be  modified  or  replaced  as  part  of  routine  maintenance,  error  correction, 
or  system  upgrade,  with  intentional  or  inadvertent  modification  of  its  function. 

5.  Asynchronous  function 

A  service  may  be  used  simultaneously  and  asynchronously  by  other  flows,  and  thus  pro¬ 
duce  results  dependent  on  unpredictable  history  of  use,  both  legitimate  and  illegitimate. 

These  factors  are  pervasive  behavioral  realities  of  large-scale,  network-centric  systems 
[Schneider  1999].  Dealing  with  them  is  an  enterprise  risk  management  problem  with  poten¬ 
tially  serious  consequences.  It  is  important  to  detect  when  they  have  occurred  and  take  ap¬ 
propriate  actions  to  continue  operation  in  the  environments  they  have  created.  For  mission- 
critical  flows,  these  actions  must  ensure  survivability  no  matter  what  adverse  environments 
are  encountered  [Mead  et  al.  2000].  In  today's  world,  it  is  imprudent  from  a  risk  management 
perspective  to  fail  to  fully  address  the  Uncertainty  Factors  at  all  levels  of  enterprise  and  sys¬ 
tem  operation. 
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The  mathematical  semantics  of  Flow  Structures  are  defined  to  support  development  and  veri¬ 
fication  of  flows  for  such  uncertain  environments  as  a  standard  engineering  practice.  To  al¬ 
low  for  unpredictable  behavior  of  services,  flow  semantics  permit  specification  of  only  the 
processing  that  a  flow  itself  performs,  and  not  the  processing  of  the  services  it  invokes.  Flow 
Structure  engineering  requires  definition  of  appropriate  actions  by  a  flow  for  all  possible 
responses  of  key  services,  both  desired  and  undesired.  Thus,  if  the  behavior  of  invoked  ser¬ 
vices  changes  for  any  reason,  the  specification  and  verification  of  the  invoking  flow  need  not 
change.  This  approach  accommodates  the  realities  of  today's  network  systems  and  offers  im¬ 
portant  advantages.  It  requires  for  mission  survivability  that  the  Uncertainty  Factors  be  dealt 
with  explicitly  in  design,  thereby  addressing  important  aspects  of  enterprise  risk  manage¬ 
ment.  It  permits  flows  and  reasoning  about  them  to  be  localized  yet  complete.  And  it  permits 
flows  to  be  defined  by  simple  deterministic  structures  despite  the  underlying  asynchronous 
behavior  of  their  constituent  services.  These  deterministic  structures  can  be  refined,  ab¬ 
stracted,  and  verified  using  straightforward  compositional  methods  for  human  understanding 
and  intellectual  control. 


It  turns  out  that  these  objectives  require  extension  of  the  traditional  functional  semantics 
model.  The  FSQ  semantic  model  is  based  on  the  well-known  concept  of  services  as  rules  for 
mathematical  functions  (or  relations  if  flows  include  concurrent  operations),  that  is,  map¬ 
pings  from  domains  (inputs,  stimuli)  to  ranges  (outputs,  responses)  [Linger  et  al.  1979,  Mills 
et  al.  1986,  Prowell  et  al.  1999,  Hoffman  and  Weiss  2001,  Mills  and  Linger  2002].  The  key 
extension  required  to  deal  systematically  with  the  Uncertainty  Factors  is  to  make  the  histories 
of  service  invocations  themselves  part  of  the  specified  behavior  of  flows.  Mathematically, 
this  is  achieved  by  including  the  invocation  stimulus  history  (ISH)  of  every  service  in  the 
range  of  the  function  that  represents  the  specification  of  a  flow.  In  addition,  because  subse¬ 
quent  flow  processing  can  depend  on  the  responses  from  these  invocations,  the  invocation 
response  history  (IRH)  must  be  part  of  the  domain  of  the  mathematical  function  that  repre¬ 
sents  the  specification  of  a  flow.  The  diagram  of  Figure  6  illustrates  these  semantics  for  a 
flow  F  invoking  a  service  A. 


Figure  6:  Elements  of  Flow-Service  Semantics 

1  is  the  set  of  possible  inputs  to  flow  F,  and  O  is  the  set  of  possible  outputs  from  flow  F. 

Thus,  the  semantics  of  F  can  be  given  by  a  mathematical  function  f  with  domain  I  x  IRH  and 
range  O  x  ISH.  It  is  this  counterintuitive  inclusion  of  service  responses  in  the  domain  of  F 
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and  service  stimuli  in  the  range  of  F  that  allows  flows  to  deal  with  the  Uncertainty  Factors. 
In  particular,  IRH  represents  the  range  of  possible  service  responses,  and  thus  embodies  the 
Uncertainty  Factor  possibilities  that  should  be  dealt  with  in  flow  design.  Dealing  with  the 
Uncertainty  Factors  requires  assessing  and  acting  upon  all  possible  responses,  desired  and 
undesired,  that  service  invocations  can  produce.  Of  course,  no  semantics  can  force  such  in¬ 
formed  design,  they  can  only  illuminate  the  desirability  of  doing  so. 


In  this  semantic  model,  the  specification  of  flow  F  is  not  required  to  account  for  the  behav¬ 
iors  that  result  due  to  invocation  of  service  A.  Rather,  it  simply  defines  the  invocation  of  ser¬ 
vice  A  with  certain  parameters,  and  how  the  response  from  that  invocation  affects  subsequent 
processing  of  F.  This  means,  for  example,  that  any  lower-level  services  invoked  by  service  A 
need  not  be  part  of  the  ISH  and  IRH  of  flow  F.  If  this  were  not  the  case,  the  specification  of 
F  would  change  if  service  A  was  modified,  for  example,  to  invoke  different  lower-level  ser¬ 
vices.  This  approach  differs  from  traditional  functional  semantics,  where  the  specification  of 
F  would  be  required  to  include  the  full  effects  of  all  lower-level  service  invocations  by  ser¬ 
vice  A  as  a  part  of  its  functional  specification. 


This  approach  to  specification  is  key  to  maintaining  intellectual  control  over  flow  specifica¬ 
tion  and  design.  As  noted,  deterministic  flows  that  invoke  non-deterministic,  asynchronous 
services  can  be  modeled  by  deterministic  mathematical  functions,  making  human  reasoning 
and  analysis  much  simpler.  Alternately,  if  the  behavior  of  flows  were  non-deterministic,  then 
the  flows  themselves  would  become  far  more  complicated,  and  their  semantics  would  need  to 
be  expressed  as  a  mathematical  relation  from  domain  I  x  IRH  to  range  O  x  ISH.  This  com¬ 
plex  situation  is  avoided  by  FSQ  semantics. 


The  flow  semantics  described  above  are  particularly  suited  to  the  common  situation  where 
service  A  already  exists  on  a  network,  or  is  provided  by  COTS  or  ESP  components  with 
complex  and  possibly  unknown  functions.  In  cases  where  service  A  is  new  and  must  be  de¬ 
signed  as  part  of  the  implementation  of  flow  F,  these  flow  semantics  can  be  combined  with 
traditional  design  and  verification  methods  such  as  those  found  in  object-based  box  structures 
[Mills  et  al.  1986]  to  support  reasoning  about  the  combined  behavior  of  the  system  consisting 
of  F  and  A  together.  In  this  way,  the  desired  behavior  of  F  and  A  can  be  used  to  guide  the 
construction  of  A.  In  particular,  box  structures  provide  history-,  state-,  and  procedure- 
oriented  representations  of  flows  and  services,  and  methods  for  their  abstraction,  refinement, 
and  verification. 


Flow  Structure  concepts  and  techniques  apply  to  network  flows  written  in  almost  any  impera¬ 
tive  language,  including  C++  and  Java,  provided  the  language  includes  the  basis  set  of  con¬ 
trol  structures,  namely,  sequence,  alternation,  and  iteration.  Specializations  and  extensions  of 
these  structures  are  valuable  as  well.  Service  invocations  in  these  languages  are  method  calls 
on  objects.  An  abstract  Flow  Structure  Language  (FSL)  can  be  defined  that  captures  the  es¬ 
sence  of  FSQ  concepts  independently  of  specific  implementation  language  syntax.  To  deal 
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with  concurrency  within  a  flow  itself,  a  concurrent  structure  is  included  in  FSL  as  well.  Be¬ 
cause  specifics  of  language  data  type  and  declaration  syntax  do  not  affect  the  applicability  of 
FSQ,  these  features  can  be  de-emphasized  in  FSL.  Figure  7  illustrates  typical  FSL  control 
structures. 


Figure  7:  Typical  FSL  Control  Structures 

The  overall  behavior  of  an  individual  flow  is  as  follows:  A  flow  is  invoked  with  values  as¬ 
signed  to  its  input  parameters,  and  at  the  termination  of  flow  execution,  the  final  values  of 
output  parameters  are  returned  to  the  invoker  of  the  flow,  whether  a  human  user  or  another 
flow.  A  flow  can  define  local,  non-persistent  data  to  store  intermediate  values  produced  by 
flow  computations.  Finally,  a  flow  can  invoke  services  to  accomplish  various  network  or 
even  local  activities,  including  storing,  accessing,  and  modifying  persistent  data.  In  design¬ 
ing  flows,  this  means  that  the  persistent  state  required  by  a  flow  should  be  encapsulated  in 
services. 

In  addition  to  sequence,  alternation,  iteration,  and  concurrent  structures,  FSL  contains  a  “use” 
statement  to  invoke  services.  The  statement  incorporates  post-fix  predicates  to  evaluate  and 
act  upon  designer-defined  equivalence  classes  on  the  set  of  all  possible  responses,  both  desir¬ 
able  and  undesirable.  This  partitioning  and  analysis  of  response  equivalence  classes  ad¬ 
dresses  the  requirement  to  deal  with  the  Uncertainty  Factors  characteristic  of  network  behav¬ 
ior,  and  the  survivability  implications  they  impose.  Flow  designers  select  key  services  for 
such  response  analysis.  The  general  syntax  of  the  use  statement  is  as  follows: 

use  <service> . <method> (<parameters>) 
response  <status_variable>  is 

<enumerated_value_l>  when  <expression> 
j  <enumerated_value_2>  when  <expression> 

j  <enumerated_value_n>  when  <expression> ; 

For  example,  the  following  use  statement  illustrates  invocation  of  an  airline  reservation  data¬ 
base  to  reserve  space  on  a  flight: 

use  Airline . reserve (customer ,  flight,  date,  result,  seat) 
response  status  is 
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NOTRESERVED  when  result  =  false 
|  RESERVEDNOSEAT  when  (result  =  true)  and  (seat  =  "") 

I  RESERVEDWITHSEAT  when  (result  =  true)  and  (seat  !=  '"'); 

In  addition  to  such  explicitly  enumerated  equivalence  classes  on  the  response,  parameters 
based  on  network  and  component  status  (e.g.,  NOTCONNECTED,  NORESPONSE)  could  be 
evaluated  as  well.  Such  evaluations  are  important  in  assessing  and  acting  upon  dynamic  sur¬ 
vivability  properties  of  a  network. 


3.2  FSQ  Theorems 

A  number  of  theorems  capture  and  explore  the  fundamentals  of  FSQ  semantics.  Example 
theorems  are  described  below.  Proofs  are  beyond  the  scope  of  this  paper  and  can  be  found  in 
[Pleszkoch  et  al.  2002]: 

1 .  Flow  Structure  Theorem 

Given  any  graph  representing  a  flow  there  exists  an  equivalent  flow  that  can  be  imple¬ 
mented  using  only  composition,  alternation,  and  iteration  control  structures. 

Engineering  Implications: 

This  theorem  guarantees  that  composition,  alternation,  and  iteration  control  structures 
are  sufficient  to  implement  any  flow.  Thus,  flow  developers  need  not  use  unstructured 
logic  or  arbitrary  branches. 

2.  Abstraction/Refinement  Theorem 

Two  flows  F  and  G  are  equivalent  in  any  network  environment  if  and  only  if  they  have 
identical  flow  specifications. 

Engineering  Implications: 

This  theorem  is  the  basic  justification  that  FSQ  mathematical  semantics  are  correct.  It 
consists  of  two  parts,  necessity  and  sufficiency.  Sufficiency  states  that  any  two  flows 
that  have  the  same  mathematical  specification  can  be  interchanged  without  affecting  the 
results  of  any  larger  network  environment.  Necessity  states  that  for  any  two  flows  that 
have  different  mathematical  specifications,  there  exists  a  larger  network  environment 
that  will  produce  different  results  if  they  are  interchanged.  In  essence,  this  theorem  says 
that  everything  that  is  important  about  the  behavior  of  a  flow  from  the  point  of  view  of 
the  external  network  is  contained  in  its  specification. 

3.  Flow  Verification  Theorem 

The  basis  set  of  single-entry,  single -exit  control  structures  that  comprise  flow  designs 
can  be  verified  by  evaluating  the  function  equations  shown  below  for  representative 
structures.  Each  equation  is  followed  by  a  statement  of  a  Correctness  Question  that  ar¬ 
ticulates  the  verification  conditions.  Verification  requirements  for  similar  control  struc¬ 
tures  are  easily  derived.  In  order  to  support  function  composition  of  flow  specifications 
in  verification  operations,  their  domain  and  range  must  be  extended  to  a  common  super- 
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set.  In  the  case  of  a  flow  specification  [F]  =  f  :  I  x  IRH  ->  O  x  ISH,  f  is  first  extended  to 
the  function  f  :  S  x  IRH  ->  S  x  ISH,  where  S  is  the  functional  verification  state  space 
corresponding  to  the  input  and  output  parameters  and  local  variables  of  the  flow  F. 

Next,  f  is  extended  to  the  function  f"  :  S  x  IRH  x  ISH  ->  S  x  IRH  x  ISH,  given  by 
f"(s,rh,sh)  =  (s',  rh',  sh'),  where  (s',  sh')  =  f  (s,rh),  and  rh'  is  equal  to  rh  with  the  first  n 
elements  removed,  where  n  is  the  length  of  sh'.  By  making  this  extension,  the  semantics 
of  an  entire  flow  can  be  calculated  by  a  functional  verification  trace  table  with  an  extra 
column  for  the  response  history  variable  rh.  Thus,  for  a  given  flow  specification  f,  ser¬ 
vices  g  and  h,  predicate  p,  and  for  all  possible  arguments  to  f,  control  structures  can  be 
verified  as  follows:  [Mills  1988,  Prowell  et  al.  1999]: 

Composition  structure: 

f  =  g;  h  Does  g  followed  by  h  do  f? 

Alternation  structure: 

p  — >  f  =  g  I  ~p  — >  f  =  h  Whenever  p  is  true,  does  g  do  f?  and 

Whenever  p  is  false,  does  h  do  f? 

Iteration  structure: 

termination  a  Does  the  iteration  terminate?  and 

p  — >  f  =  g  o  f  a  Whenever  p  is  true  does  g  followed  by  f  do  f?  and 

~p  — >  f  =  null  Whenever  p  is  false,  does  doing  nothing  do  f? 

Engineering  implications: 

The  Flow  Verification  theorem  reduces  verification  to  a  finite  and  complete  process  de¬ 
spite  the  fact  that  flows  can  contain  a  virtually  infinite  number  of  paths.  Verification  can 
be  carried  out  using  Trace  Tables  [Prowell  et  al.  1999]  as  a  formal  analysis  and  docu¬ 
mentation  process  for  critical  system  parts,  or  applied  in  team  reviews  with  greater  speed 
and  little  loss  of  precision. 

4.  Flow  Implementation  Theorem 

For  each  computable  function  f  from  I  x  IRH  ->  O  x  ISH  that  satisfies  the  following 
condition,  there  exists  a  flow  F  such  that  [F]  =  f. 

Condition:  For  every  n  >  0,  there  exists  a  function  fn  :  I  x  IRn  ->  O  x  IS<n+1>,  where  IRn  is 
the  first  n  elements  of  IRH,  and  IS(n+1)  is  the  first  (n+1)  elements  of  ISH,  such  that  the 
following  diagram  commutes: 
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where  PIn  :  I  x  IRH  ->  I  x  IRn  is  given  by  PIn(i,  l'h)  =  (i,  first  n  elements  of  rh),  and  PO„  : 
O  x  ISH  ->  O  x  IS(n+1)  is  given  by  POn(0,  sh)  =  (null,  first  n+1  elements  of  sh)  if  sh  has  at 
least  n+1  elements,  and  by  POn(0,  sh)  =  (0,  sh)  if  sh  has  n  or  fewer  elements. 

Engineering  Implications: 

Every  flow  F  has  a  function  [F],  but  it  turns  out  that  not  every  function  f  corresponds  to 
a  flow.  This  theorem  defines  which  functions  do  in  fact  correspond  to  flows.  Infor¬ 
mally,  the  condition  states  that  a  function  cannot  require  a  flow  to  predict  the  future,  by 
making  decisions  based  on  responses  from  services  before  those  services  are  actually  in¬ 
voked.  The  theorem  states  that  any  flow  semantics  that  meets  this  condition  can  actually 
be  implemented.  Thus,  this  theorem  is  important  to  take  into  account  when  designing 
flows  top-down. 


5.  System  Testing  Theorem 

Let  D|  be  a  usage  distribution  on  the  input  of  a  flow  F,  and  let  DR  be  a  usage  distribution 
on  the  responses  to  the  external  service  calls  made  by  F.  Then  the  usage  distribution  Ds 
on  the  stimuli  of  the  external  service  calls  made  by  F  can  be  calculated  from  DIt  DR,  and 
[F]. 

Engineering  Implications: 

Systems  of  any  size  exhibit  a  virtually  infinite  population  of  possible  executions.  There¬ 
fore,  all  testing  is  sampling,  and  the  only  real  question  is  how  to  draw  the  sample  of  test 
cases  to  be  executed.  If  a  sample  is  representative  of  actual  field  usage,  scientifically 
valid  predictions  based  on  the  sample  test  results  can  be  made  for  the  population  of  all 
executions  not  tested,  which,  of  course,  users  will  encounter  in  field  usage.  Such  mod¬ 
ern  usage-based  statistical  testing  supports  effective  test  management  and  risk  reduction 
processes.  Flow  specifications  and  effective  system  testing  processes  are  closely  related. 
Flows  define  how  systems  are  used.  Given  usage  frequencies  for  flows  that  define  when 
and  how  they  are  used,  it  is  possible  to  predict  the  usage  of  their  services.  Such  predic¬ 
tions  can  populate  the  probability  distributions  of  usage  models  that  are  employed  to 
generate  test  cases  (samples  of  the  execution  population)  statistically  faithful  to  antici¬ 
pated  usage.  Such  an  approach  to  testing  permits  valid  estimates  of  system  performance 
in  field  use,  and  thus  guides  test  management  and  product  release  decisions. 


Other  theorems  provide  additional  foundations  for  FSQ  engineering  operations,  including 
transitive  analysis  of  flow  dependencies  and  derivation  of  logical  system  architectures  from 
flows. 
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4  Flow  Structure  Engineering  Operations 


Flow  Structures  support  many  engineering  operations  in  network  system  analysis  and  devel¬ 
opment.  Some  representative  operations  are  briefly  described  below: 


4.1  Flow  Engineering  for  Uncertainty  Factors 

Uncertainty  Factor  engineering  requires  that  flows  address  all  possible  responses  (IRH)  from 
critical  services.  This  engineering  process  requires  definition  of  post-fix  predicates  on  re¬ 
sponses  to  determine  and  design  appropriate  actions.  Responses  can  be  organized  by  design¬ 
ers  into  subject-matter-dependent  equivalence  classes  of  interest.  These  equivalence  classes 
are  the  subject  matter  of  risk  management  and  mission  continuity  in  survivability  engineer¬ 
ing.  It  is  up  to  designers  to  select  those  critical  service  invocations  that  should  undergo  re¬ 
sponse  analysis. 


Figure  8  illustrates  use  of  post-fix  predicates  in  a  notional  fragment  of  an  air  traffic  control 
flow.  A  controller  using  the  flow  is  expecting  to  identify  an  aircraft  (use  a/c  ident)  and  obtain 
its  position  fix  (use  a/c  position  fix).  Three  post-fix  predicates  follow  the  invocation  of  the 
a/c  ident  service.  These  predicates  parse  the  service  response  into  equivalence  classes  deal¬ 
ing  with  whether  any  response  was  received,  whether  it  was  an  aircraft  identification,  and 
whether  it  was  a  valid  aircraft  identification.  In  this  small  example,  each  case  of  negative 
evaluation  notifies  the  controller  through  the  controller  interface  service.  But  consider  de- 
sign-time  issues  and  discussions  in  development  of  a  system  to  support  this  mission-critical 
flow.  Failure  of  the  a/c  ident  service  is  a  very  serious  matter  impacting  completion  of  the 
flow  and  thereby  the  safety  of  aircraft.  Transitivity  analysis  of  other  flows  upon  which  a/c 
ident  depends  may  reveal  a  whole  series  of  cascade  failure  possibilities  that  must  be  dealt 
with  to  ensure  survivability  of  this  critical  service.  Such  analysis  may  result  in  major 
changes  to  the  proposed  system  architecture.  In  any  event,  it  should  become  clear  that  notifi¬ 
cation  of  the  controller  is  an  insufficient  action  for  this  serious  problem,  and  that  this  flow 
must  be  redesigned.  Note  in  this  discussion  that  the  semantics  of  Flow  Structures  permit  de¬ 
signers  to  define  and  act  upon  response  equivalence  classes  that  encompass  the  Uncertainty 
Factors.  This  supports  enterprise  risk  management,  which  requires  analysis  of  all  possible 
outcomes,  and  survivability  management,  which  requires  actions  for  all  possible  outcomes. 
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Figure  8:  Post- Fix  Service  Response  Evaluation  for  Survivability  Analysis  and  Risk 
Management 


4.2  Flow  Abstraction  and  Refinement 

The  single -entry,  single -exit  basis  set  of  control  structures  that  comprise  FSL  can  be  com¬ 
posed  and  nested  to  create  Flow  Structures  of  any  size  and  complexity.  As  noted  above, 
flows  and  their  constituent  control  structures  implement  mathematical  functions  or  relations, 
that  is,  mappings  from  domains  to  ranges.  These  functions  define  data  to  be  transformed 
from  initial  to  final  values,  and  can  be  included  in  flows  as  comments  attached  to  their  con¬ 
trol  structure  refinements.  They  can  be  defined  in  a  spectrum  of  forms,  ranging  from  natural 
language  to  more  mathematics-based  notations. 


An  algebra  of  functions  permits  precise  abstraction  and  refinement  in  the  substitution  of  func¬ 
tion  definitions  for  their  refinements  (abstraction  to  determine  what  flows  actually  do)  or 
substitutions  of  designs  for  their  function  definitions  (refinement  to  implement  what  flows 
are  intended  to  do).  Figure  9  depicts  these  operations  in  abstract  form.  Design  abstraction 
occurs  in  moving  left  to  right,  where  the  overall  function  of  the  flow  is  abstracted  in  three 
steps  to  function  C.  Design  refinement  occurs  in  moving  right  to  left,  where  the  full  elabora¬ 
tion  of  function  C  is  achieved  in  three  steps. 
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Figure  9:  Algebraic  Operations  in  Flow  Structure  Analysis  and  Design 

Figure  10  provides  a  miniature  notional  illustration  of  flow  refinement  and  abstraction  based 
on  the  example  of  a  gasoline  purchase  transaction.  This  informal  depiction  shows  the  flow  at 
a  mission  level  of  abstraction  that  is  refined  into  a  specification  of  principal  operations  and 
their  composition.  The  first  specified  operation  is  further  refined  into  a  high-level  design. 
Abstraction  reverses  this  process  ending  in  the  mission  description  of  the  flow  [Hausler  et  al. 
1990.  Pleszkoch  et  al.  1990]. 


Figure  10:  Flow  Abstraction  and  Refinement  in  a  Transaction-Based  System 

Informal  methods  of  abstraction  and  refinement  are  depicted  in  Figure  10.  However,  the  se¬ 
mantics  of  Flow  Structures  permits  these  operations  to  be  carried  out  with  precision,  to  sup¬ 
port  predictable  assembly  of  components  in  composition  operations,  and  to  allow  verification 
of  components  with  respect  to  their  specifications. 


CMU/SEI-2002-TN-01 9 


21 


4.3  Flow  Verification 


The  Flow  Verification  theorem  provides  the  basis  for  an  effective  team-oriented  assurance 
process.  Flows  annotated  with  function  definitions  of  their  constituent  control  structures  can 
be  verified  in  structured  team  reviews  that  ask  and  answer  the  Correctness  Questions  and  re¬ 
quire  unanimous  agreement  on  each  question. 


Flows  may  contain  a  virtually  infinite  number  of  possible  execution  paths  impossible  to  ver¬ 
ify  on  an  individual  basis.  However,  they  are  composed  of  a  finite  number  of  control  struc¬ 
tures,  and  the  Flow  Verification  Theorem  permits  every  control  structure  to  be  verified  in  a 
finite  number  of  steps  [Mills  et  al.  1986,  Prowell  et  al.  1999],  One  step  is  required  for  se¬ 
quence  verification  (function  composition),  two  steps  for  alternation  verification  (true  and 
false  case  analysis),  and  three  steps  for  iteration  verification  (termination  proof,  plus  true  and 
false  case  analysis  and  function  composition).  Thus,  verification  is  reduced  to  a  finite  proc¬ 
ess  amenable  to  team  operations.  Such  team  verifications  are  cost  effective  in  detecting  prob¬ 
lems  and  errors  early  in  development  for  correction  at  lowest  cost.  Figure  1 1  illustrates  the 
flow  verification  process.  As  shown  on  the  left,  a  miniature  flow  composed  of  a  sequence 
followed  by  an  alternation  is  to  be  verified.  The  sequence,  the  alternation,  and  the  composi¬ 
tion  of  these  two  structures  must  each  be  verified  to  be  correct  with  respect  to  their  intended 
functions.  Errors  are  discovered  in  the  center  of  the  figure  based  on  application  of  the  Cor¬ 
rectness  Questions,  and  are  shown  corrected  on  the  right. 


A  flow  annotated  with 
function  descriptions  of 
its  three  structures 


Each  structure  is  evaluated 
against  its  function  using  the 
Correctness  Questions 


Two  errors  are  fixed  and 
all  structures  pass 
evaluation 


lows  can  have  infinite' 
paths,  but  verification 
is  finite  and  complete^ 


□ 

Intended  function 

Q  Correct 

□ 

Service  use: 
correctness  unknown 

P|  Incorrect 

Figure  11:  The  Correctness  Evaluation  Process  Based  on  the  Flow  Verification 
Theorem 
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Each  verification  of  a  control  structure  against  its  intended  function  requires  only  local  rea¬ 
soning,  and  the  verifications  can  be  carried  out  in  any  order.  When  more  precision  is  re¬ 
quired  for  critical  flows,  verification  can  be  accomplished  with  trace  tables  to  document  rea¬ 
soning  and  analysis.  When  a  service  is  provided  by  a  COTS  component  with  complex 
functionality,  it  is  necessary  only  to  verify  the  use  actually  made  of  the  component.  This 
verification  will  include  the  equivalence  class  evaluations  that  account  for  all  possible  out¬ 
comes  of  the  COTS  invocation. 


4.4  Flow  Transitivity  Analysis 

Flows  may  invoke  services  composed  of  flows  that  may  likewise  invoke  services  composed 
of  flows  at  a  lower  level,  etc.  Thus,  a  primary  flow  may  depend  on  completion  of  many  other 
flows,  possibly  distributed  across  many  components  in  a  large-scale  network.  Transitivity 
analysis  of  flows  can  reveal  such  dependencies  for  analysis  of  survivability  and  other  quality 
attributes. 


Figure  12  depicts  the  beginning  of  such  an  analysis  for  the  Future  Combat  System.  The  pri¬ 
mary  mission  control  flow  in  the  center  of  the  figure  named  Target  Attack  invokes  a  sensor 
data  service  and  its  flow  provided  by  a  UAV  node,  and  a  fire  control  service  and  its  flow  pro¬ 
vided  by  a  robotic  direct  fire  node.  These  flows  in  turn  invoke  other  services  local  to  their 
nodes.  So  the  first  step  in  transitivity  analysis  is  to  determine  what  services  and  their  flows 
are  directly  invoked  in  satisfying  a  primary  flow.  In  addition,  every  flow  can  exhibit  both 
desired  and  undesired  outcomes  as  defined  by  equivalence  classes  on  service  responses. 
Clearly,  what  is  intended  in  a  flow  invocation  is  a  desired  outcome.  It  is  often  the  case  that 
desired  outcomes  depend  on  successful  completion  of  flows  not  directly  invoked.  For  exam¬ 
ple,  to  be  operational  at  all,  a  UAV  component  must  have  undergone  successful  completion  of 
flows  dealing  with  inventory,  training,  maintenance,  weather  analysis,  mission  definition, 
fueling,  launch,  and  flight,  to  name  a  few,  in  order  for  a  desired  outcome  to  be  obtained  when 
the  sensor  data  service  is  invoked.  This  chain  of  dependencies  represents  the  complete  set  of 
UAV  flows  that  supports  the  mission  of  the  primary  target  attack  flow.  Such  analysis  can 
reveal  surprising  and  often  unforeseen  dependencies  that  must  be  dealt  with  to  ensure  surviv¬ 
ability  of  mission  flows.  Flows  important  to  enterprise  objectives  may  be  vulnerable  to 
poorly  designed  and  implemented  flows  that  would  otherwise  be  hardly  noticed  given  their 
physical  or  temporal  separation  from  primary  mission  flows. 


Mission-oriented  flows  compose  and  integrate  local  network  services  into  coherent  capabili¬ 
ties  that  are  the  reason  for  existence  of  the  network  system  in  the  first  place.  As  such,  they 
serve  as  overarching  specifications  for  network-level  capabilities  and  the  local  services  that 
support  them. 
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Figure  12:  Transitivity  Analysis  of  Flow  Dependencies 


4.5  FlowSets  in  Large-Scale  Systems 

Large-scale  systems  typically  contain  components  that  are  complex  systems  in  their  own 
right.  As  such,  these  components  support  services  and  flows  that  manage  and  use  their  own 
capabilities,  as  well  as  participate  in  inter-component,  network-spanning  flows.  It  is  often 
useful  to  group  services  and  flows  that  support  particular  components  or  functions.  Such 
groupings  are  termed  FlowSets. 


For  example,  consider  FlowSets  associated  with  the  Future  Combat  System  as  depicted  in 
Figure  13.  Each  sensor  and  weapons-delivery  node  is  a  full-scale  system  exhibiting  complex 
functionality,  with  its  own  acquisition,  development,  and  evolution  life  cycles,  and  unique 
operational  capabilities,  vulnerabilities,  and  constraints.  These  nodes  are  designed  to  support 
local  FlowSets  dealing  with  achieving  and  maintaining  operational  capabilities.  But  they  are 
also  designed  to  participate  in  network-centric  operations  to  accomplish  overarching  mission 
objectives.  In  the  illustration  at  the  center  of  Figure  13,  a  FlowSet  is  defined  that  supports 
mission  operations  by  traversing  and  integrating  the  capabilities  of  network  components  into 
coherent  overall  capabilities.  For  example,  sensor  integration  flows  in  the  FlowSet  combine 
the  outputs  of  layered  sensors  into  a  comprehensive  assessment  of  attack  opportunities.  Fire 
integration  flows  select  and  coordinate  attack  elements,  and  damage  assessment  flows  inte¬ 
grate  sensor  reports  of  attack  outcomes.  Such  network-centric  FlowSets  combine  the  capa¬ 
bilities  of  individual  systems  to  achieve  mission  objectives. 


So  the  task  of  network-centric  system  development  is  to  define  FlowSets  for  individual  sys¬ 
tems  that  seamlessly  support  mission  FlowSets.  And  mission  FlowSets  must  be  designed  to 
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integrate  these  systems  into  coherent  capabilities.  In  this  role,  mission  FlowSets  are  the  pri¬ 
mary  specification  of  network  capabilities,  and  systems  within  the  network  must  be  designed 
to  support  them. 
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Figure  13:  Flow-Sets  for  the  Future  Combat  System 


4.6  Flow  Security  and  Survivability  Analysis 

Flows  represent  end-to-end  processing,  that  is,  traversals  from  a  user  (e.g.  person  or  flow) 
through  a  network  and  back  to  the  user.  Many  systems  and  domains  may  be  visited  in  such 
traversals,  each  with  its  own  security  and  survivability  policies  and  capabilities.  This  situa¬ 
tion  is  depicted  in  Figure  14  for  the  gas  purchase  transaction  example.  It  is  this  end-to-end 
transaction  that  must  be  secure  and  survivable.  Quality  attributes  for  these  properties  can  be 
defined  for  the  overall  flow,  as  benchmark  requirements  that  all  traversed  systems  and  do¬ 
mains  must  provide.  Security  and  survivability  can  be  analyzed  with  respect  to  flow  propa¬ 
gation,  and  are  only  as  good  as  the  least  capable  components.  Some  flows  must  be  more  se¬ 
cure  and  survivable  than  others,  and  service  vendors  and  providers  may  offer  a  spectrum  of 
quality  of  service  guarantees.  It  is  often  the  case,  however,  that  flows  must  negotiate  for  ser¬ 
vices  and  quality  attributes  in  real  time.  This  is  the  basic  FSQ  model,  where  attribute  re¬ 
quirements  associated  with  flows  are  dynamically  reconciled  with  network  capabilities. 


Flow  Structures  are  an  important  element  of  the  System  Survivability  Analysis  (SSA)  tech¬ 
nique  developed  by  the  SEI  CERT  Coordination  Center  [Ellison  et  al.  1999a,  Ellison  et  al. 
1999b,  Linger  et  al.  2000,  Mead  et  al.  2000],  SSA  is  a  structured  engineering  process  aimed 
at  improving  survivability  characteristics  of  new  or  existing  systems.  It  has  been  applied  to  a 
number  of  government  and  commercial  systems  with  good  results.  The  SSA  process  identi¬ 
fies  mission-essential  system  flows,  that  is,  flows  that  must  be  available  no  matter  what  the 
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threat  environment  and  state  of  compromise.  These  flows  of  service  uses  are  traced  through 
the  system  architecture  to  reveal  corresponding  essential  components.  Next,  representative 
intrusions  are  identified  based  on  analysis  of  the  threat  environment,  and  expressed  as  flows 
for  tracing  through  the  architecture  to  reveal  compromisible  components.  With  this  informa¬ 
tion  it  is  possible  to  identify  softspot  components  that  are  both  essential  and  compromisible, 
followed  by  survivability  analysis  for  improvements  to  resistance,  recognition,  and  recovery 
strategics  within  the  system  architecture. 


Figure  14:  Flow  Security  and  Survivability  Domain  Traversals 

These  six  engineering  operations  illustrate  some  basic  uses  of  Flow  Structure  concepts  and 
techniques.  Additional  engineering  operations  include  derivation  of  logical  network  struc¬ 
tures  from  FlowSets,  and  definition  of  statistical  usage  models  of  network  systems  for  test 
case  generation  based  on  FlowSet  usage  patterns  and  probabilities. 
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5  Computational  Quality  Attributes 


Unless  a  system  is  implemented  on  a  closed  internal  network,  many  system  details  may  be 
unknowable.  Nevertheless,  enterprises  place  extraordinary  demands  on  systems  for  reliabil¬ 
ity,  availability,  security,  and  other  key  quality  attributes  [Haeckel  1999],  Substantial  effort 
has  been  devoted  to  development  of  descriptive  and  often  subjective  characterizations  of 
quality  attributes,  for  example,  survivability  attributes  [Ellison  et  al.  1999c,  Sullivan  et  al. 
1999],  Rather  than  focusing  on  descriptive  methods,  the  Computational  Quality  Attributes 
(CQA)  approach  defines,  computes,  and  acts  upon  quality  attributes  as  dynamic  characteris¬ 
tics  of  system  operation.  This  section  describes  mathematical  foundations  and  frameworks 
for  these  operations. 


Many  researchers  have  addressed  component-based  quality  attributes,  such  as  reliability, 
from  the  perspective  of  the  system  as  a  whole  [Siegrist  1988,  Krishnamurthy  and  Mathru 
1997,  Gokhale  and  Trivedi  1998,  Yacoub  et  al.  1999,  Hamlet  et  al.  2001].  However,  from  the 
perspective  of  a  user  of  a  distributed  system,  there  is  no  need  for  a  system  view  of  quality 
attributes.  The  user  is  concerned  with  the  provision  of  essential  services,  not  the  state  of  the 
system.  The  CQA  approach  addresses  the  user's  concern.  Quality  attributes  are  defined  at  the 
service  level,  composed  to  the  service  and  flow  levels,  and  evaluated  at  either  the  service  or 
flow  level,  or  at  both  levels,  depending  on  the  user-specified  CQA  request.  This  CQA  ap¬ 
proach,  illustrated  in  Figure  15,  provides  a  consistent  semantic  framework  for  acquiring  qual¬ 
ity  attribute  performance  information  for  essential  flows  and  services,  and  for  computing  sys¬ 
tem  quality  capabilities  for  run-time  management  of  flow  execution. 


5.1  The  CQA  approach 

CQAs  are  defined  as  a  functional  mapping  of  usage  (i.e.  the  input  domain  for  a  particular  use, 
environment,  and  time)  into  attribute  values  that  represent  a  measure  of  quality.  This  ap¬ 
proach  supports  the  description  of  any  set  of  quality  attributes  and  any  models  used  to  de¬ 
scribe  each  attribute,  provided  each  model  yields  a  numeric  value. 
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Figure  15:  The  Computational  Quality  Attribute  Approach 

The  developer  defines  CQAs  of  interest  and  initializes  projected  CQA  values  for  each  service 
based  on  assertions  from  vendors,  best  estimates,  historical  records,  etc.  During  operational 
use  of  the  system,  the  following  activities  are  iteratively  performed  as  services  are  executed: 

•  Service  executions  are  monitored  and  their  quality  attributes  are  measured. 

•  The  quality  attribute  values  are  accumulated. 

•  The  accumulated  history  is  analyzed  and  used  to  update  projected  CQA  values  as  appro¬ 
priate.  (Note  that  a  single  observation  for  a  CQA  provides  almost  no  information.  How¬ 
ever,  over  time,  the  cumulative  weight  of  the  execution  histories  informs  the  methods  for 
predicting  CQAs  for  service  instances.) 


The  user  requests  flows  of  services  to  be  performed  by  the  system.  Flow  requests  include  re¬ 
quired  levels  of  CQAs  for  the  requested  flow,  as  well  as  for  execution  of  the  individual  ser¬ 
vices  they  reference.  Thus,  user-requested  CQAs  define  constraints  for  flow  execution. 


The  system  administrator  uses  the  CQA  history  to  support  decisions  concerning  updates  to 
the  distributed  systems  (e.g.  load  balancing  and  replicated  services).  The  system  administra¬ 
tor's  knowledge  of  the  state  of  the  system  and  its  services  can  provide  valuable  insights  to 
support  interpretation  of  the  CQA  history. 


Because  each  service's  CQAs  can  be  calculated  independently  of  other  services  and  system 
components,  both  the  implementation  of  the  component  and  the  distribution  of  the  instances 
of  the  component  can  provide  a  variety  of  opportunities  to  achieve  desired  values  for  CQAs 
of  interest.  Multiple  choices  may  be  available  to  the  designer  of  a  component  for  implementa- 
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tion  of  a  service,  each  choice  with  different  values  for  quality  attributes.  In  addition,  the  sys¬ 
tem  administrator  may  distribute  one  or  more  instances  of  a  particular  implementation  of  a 
service  across  a  network,  where  each  distribution  may  yield  different  values  for  CQAs. 


5.2  CQA  Definition 

The  general  model  for  definition  of  a  CQA,  q,,  is  a  hierarchy  of  functional  definitions: 


q,  =  f(q,j,  q,,2. 


...),  where  qu  =  g(qi>u,  qu,2,...) 


Each  CQA  has  a  precise  meaning  and  a  formal  functional  representation.  In  general,  the  pro¬ 
cess  of  CQA  definition  can  be  described  as  follows: 

•  Determine  the  quality  attributes  of  interest. 

•  Recursively  define  the  functions  for  a  quality  attribute  as  a  hierarchy  of  functional  defini¬ 
tions  of  attributes  until  each  leaf  attribute  has  been  defined  as  a  computational  function 
that  maps  usage  into  a  non-negative  real  number  that  represents  a  measure  of  quality. 

•  Determine  the  data  structure  and  procedures  for  storing  the  attribute  values. 


Note  that  measuring  and  storing  CQA  values  at  detailed  levels  can  adversely  impact  system 
performance.  Thus,  tradeoff  analyses  are  typically  required  to  determine  the  appropriate 
granularity  of  the  values  to  be  stored.  Issues  include  frequency  of  calculation,  and  whether  to 
store  actual  or  average  values. 


The  approach  to  CQA  definition  accommodates  all  degrees  of  complexity  in  quality  attribute 
definition.  Any  number  of  attributes  may  be  of  interest  to  users  of  a  distributed  system,  in¬ 
cluding  attributes  that  describe  behavioral  requirements  and  attributes  that  describe  perform¬ 
ance  characteristics.  Some  attributes  (such  as  availability,  reliability,  and  response  time)  have 
a  rich  literature  and  can  be  easily  defined  as  CQAs.  Other  attributes  will  require  more  effort 
to  develop  a  CQA  definition.  For  example:  survivability  may  be  defined  as  a  function  of  sys¬ 
tem  architecture  and  other  attributes;  system  architecture  can  be  defined  as  a  function  of  a 
variety  of  attributes  including  connectivity;  etc.  Some  example  CQA  definitions  are  provided 
in  [Walton  et  al.  2002]. 


5.3  Flow  Request  Analysis 

In  order  to  implement  the  CQA  framework  to  support  distributed  system  use,  a  system's  ser¬ 
vices  must  be  "attribute-enabled"  for  the  CQAs  of  concern  to  users.  That  is,  a  mechanism 
must  exist  to  support  CQA  evaluation  and  reporting.  This  mechanism  may  be  implemented 
directly  at  the  level  of  the  service,  or  computed  by  evaluation  and  composition  of  CQAs  from 
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lower-level  services.  A  CQA  for  which  a  service  is  not  attribute -enabled  will  yield  a  value  of 
"0"  if  any  flow  request  includes  a  constraint  on  that  attribute. 


Lower  level  CQAs  are  composed  to  establish  the  value  of  the  CQAs  on  the  next  higher  level. 
CQAs  are  also  composed  across  services  to  establish  flow  properties.  For  the  sake  of  simplic¬ 
ity,  the  CQA  approach  assumes  service  executions  are  independent.  (To  assume  otherwise 
would  require  knowledge  of  the  designs  and  implementations  of  each  of  the  components  that 
make  up  each  service.)  Because  CQAs  map  usage  into  attribute  values,  it  is  important  that 
each  CQA  value  be  determined  based  on  the  domain  of  interest  to  the  usage  flow. 


Given  a  constrained  flow  request  and  a  set  of  candidate  flows,  the  goal  of  flow  request  analy¬ 
sis  is  to  determine  whether  each  candidate  flow  satisfies  the  set  of  CQA  constraints.  If  each 
CQA  constraint  is  defined  as  a  minimum  acceptable  value,  then  the  set  of  acceptable  flows 
resides  within  a  convex  region  of  acceptable  quality  as  defined  by  the  CQA  constraints.  De¬ 
tails  of  CQA  composition  and  flow  request  analysis  are  provided  in  [Walton  et  al.  2002].  A 
high  level  description  and  a  simple  example  are  provided  here  to  illustrate  the  concepts. 


A  user  specifies  a  flow  request  as  follows: 

1 .  Define  the  flow  as  a  composition  of  system  services  that  carry  out  user  tasks. 

2.  Determine  the  CQAs  of  interest  for  this  flow  request  based  on  the  input  domain  for  this 
particular  use,  environment,  and  time. 

3.  Specify  constraints  for  the  requested  services  and  constraints  for  the  flow  in  terms  of 
acceptable  values  or  ranges  of  values  for  CQAs. 


A  flow  request  is  processed  as  follows: 

1 .  Candidate  flows  are  identified  that  provide  the  requested  composition  of  system  ser¬ 
vices. 

2.  Each  candidate  flow  is  evaluated  based  on  whether  the  set  of  projected  CQA  values  as¬ 
sociated  with  the  services  included  in  the  candidate  flow  satisfy  the  flow  request's  CQA 
constraints.  (If  multiple  candidate  flows  satisfy  the  flow  request,  negotiation  with  the 
user  may  be  performed  to  select  the  optimal  flow  based  on  user-specified  priorities.) 


Candidate  flows  are  evaluated  as  follows: 

1 .  In  addition  to  requested  services,  represent  all  network  connections  as  services. 

2.  Predict  the  values  for  each  CQA  of  interest  for  each  service  in  the  flow.  (If  a  service  is 
not  attribute -enabled  for  a  CQA  of  interest,  assign  a  value  of  0  to  that  CQA.) 

3.  Check  the  CQA  constraints  specified  for  each  service  by  comparing  the  predicted  CQA 
values  to  the  constraints.  If  all  of  the  service-level  constraints  are  satisfied,  continue  to 
the  next  step.  Otherwise  return  a  "no"  response  to  the  request. 
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4.  Check  the  flow-level  CQA  constraints: 

a.  Develop  a  state -based  graphical  model  that  includes  all  possibilities  for  satisfaction 
of  the  CQA  constraints,  including  adverse  results. 

b.  Convert  each  CQA  into  a  probability  distribution  and  annotate  the  arcs  of  the 
graphical  model  with  the  probability  distribution,  yielding  a  probabilistic  model. 
(Use  weights  as  needed  in  the  situations  where  the  CQA  units  are  not  uniform 
across  all  the  services.) 

c.  Compute  the  projected  flow-level  CQA  based  on  the  probabilistic  model. 

5.  If  the  projected  flow -level  CQA  satisfies  the  flow-level  constraints,  return  "yes".  Other¬ 
wise  return  "no". 


5.4  A  CQA  Example 

Consider  the  simple  flow  request  illustrated  by  Figure  16.  The  user  has  requested  a  flow  in¬ 
stance  that  consists  of  the  execution  of  an  instance  of  service  A  followed  by  execution  of  an 
instance  of  service  B.  The  CQA  qi  constrains  the  flow  request,  qi  is  defined  as  the  predicted 
reliability,  represented  by  a  real  number  in  the  interval  [0,1],  and  interpreted  as  the  probabil¬ 
ity  that  a  single  execution  will  not  fail. 


The  following  CQA  constraints  are  specified: 

•  Service-level  constraints:  qi  >  0.97  for  the  instance  of  service  A;  and  qi  >  0.96  for  the 
instance  of  service  B 

•  Flow-level  constraint:  qi  >  0.94  for  the  entire  flow  instance. 


A 

1 
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|  ^ 
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W\ 
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3,  >  .97  ( 

3,  >  .96 

_ y 
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Q,  >  .94 

Figure  16:  Simple  Constrained  Flow  Request 

Representing  the  connections  as  services  Coni,  Con2,  and  Con3,  assume  that  a  candidate 
flow  is  identified  with  the  following  CQA  predictions: 


qi  =  .99  for  Coni;  qj  =  .98  for  A  and  Con2;  q2  =  .97  for  B  and  Con3. 
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These  predicted  CQAs  satisfy  all  the  service-level  constraints  specified  by  the  user.  Thus,  the 
next  step  is  to  determine  whether  the  candidate  flow  satisfies  each  flow-level  constraint. 

Figure  17  illustrates  the  state  diagram  used  to  analyze  the  flow-level  CQA  constraint  qj  = 
0.95  for  the  candidate  flow.  Each  service  is  represented  by  a  state  with  two  exit  arcs:  fail  to 
satisfy  the  CQA  constraint  and  continue  to  the  next  service.  Continue  occurs  if  the  service 
satisfies  the  specified  CQA  constraint.  Failure  occurs  if  the  service  fails  to  satisfy  the  CQA 
constraint.  The  probabilities  associated  with  the  exit  arcs  for  each  service  sum  to  1.0.  In  this 
example,  if  one  assumes  independence  in  the  probabilities  that  each  service  will  not  fail,  the 
probability  that  the  candidate  flow  will  execute  without  failure  is  the  product  of  the  predicted 
q!  values  for  each  service.  At  the  flow-level,  predicted  qj  is  calculated  for  this  candidate  flow 
as  follows: 

predicted  q,  =  0.99  *  0.98  *  0.98  *  0.97*  0.97  =  0.89 

Thus,  the  candidate  flow  does  not  satisfy  the  flow-level  constraint  qi>.94. 


Figure  17:  State  Diagram  for  Analysis  of  q1 

5.5  Considerations  for  CQA  Analysis 

Transient  faults  and  considerations  of  dynamic  changes  in  the  CQAs  across  the  input  domain 
can  cause  composition  to  be  problematic,  requiring  the  use  of  policies  and  assumptions  such 
as  the  following: 

•  If  a  resource  is  not  available  when  it  is  needed  by  a  flow  instance,  the  flow  instance  will 
abort  without  waiting  for  the  resource. 

•  Flows  cannot  reserve  resources. 

•  Flow  execution  does  not  include  look-ahead. 
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•  No  repairs  or  replacements  are  done  during  a  flow. 

•  Component  and  service  failures  are  statistically  independent. 

•  Probability  distributions  associated  with  the  CQAs  do  not  change  during  the  execution  of 
a  flow. 


An  understanding  of  both  use  and  replication  is  required  before  composition  of  CQAs  can  be 
performed.  For  example,  if  three  nodes  are  each  executing  the  same  service  on  the  same  data, 
failure  of  a  node  is  not  a  problem  unless  all  three  replicated  nodes  fail.  In  contrast,  if  three 
nodes  execute  the  same  service  on  different  data,  a  failure  in  a  single  node  causes  a  failure  in 
the  flow  requiring  execution  of  the  service  on  that  node's  data. 


5.6  Dynamic  Updates  of  Computational  Quality 
Attributes 

The  algorithm  for  updating  projected  CQAs  from  the  history  must  be  sensitive  to  the  fact  that 
the  system  is  continually  evolving.  Replacement  or  maintenance  of  a  node,  communication 
link,  or  service  may  change  the  system  properties  drastically,  but  the  user  may  have  no  way 
to  know  that  the  change  occurred.  Each  use  of  the  system  may  in  fact  be  executing  on  a  dif¬ 
ferent  version  of  the  software  or  in  a  different  usage  environment  (for  example,  a  different 
network  configuration)  for  which  the  history  is  not  applicable.  Information  about  system  evo¬ 
lution  may  not  be  directly  available.  Traditional  statistical  inference  techniques  are  inade¬ 
quate  to  support  measuring  and  prediction  of  CQA  values  in  these  situations. 


To  estimate  a  value  for  a  CQA  for  an  evolving  system  for  which  the  system  state  is  unknow¬ 
able  requires  a  method  that  makes  the  best  use  of  every  source  of  available  relevant  evidence, 
including  information  obtained  from  vendors,  personal  judgment,  accumulated  history,  and 
knowledge  of  the  occurrence  of  specific  events  (updates  to  a  component,  etc.)  that  may  in¬ 
validate  the  history.  At  present  such  network-based  applications  are  often  adjusted  manually 
based  on  intuition  and  incomplete  knowledge  of  current  system  state.  The  CQA  approach 
replaces  these  informal  techniques  by  using  Bayesian  statistical  methods  to  provide  a  system¬ 
atic  response-based  approach  to  estimation  of  CQA  values.  Bayesian  statistical  methods  pro¬ 
vide  a  mathematical  framework  that  allows  representation  of  everything  known  (or  assumed) 
about  a  CQA  in  a  simple  functional  form,  and  support  updating  this  functional  form  with  new 
knowledge  as  it  becomes  available  [Lee  1989,  Royall  1997]. 


A  Bayesian  probability  is  a  formalism  that  supports  reasoning  about  beliefs  under  conditions 
of  uncertainty  and  using  disparate  sources  of  evidence.  Unlike  classical  statistical  inference, 
the  Bayesian  approach  considers  the  observations  to  be  fixed,  and  the  parameters  to  be  ran¬ 
dom  variables  with  their  own  statistical  distributions.  The  Bayesian  approach  starts  with  a 
suitable  set  of  pre-existing  beliefs  (the  "prior  distribution").  As  new  data  become  available, 
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they  are  combined  with  the  prior  distribution  to  obtain  a  new  (posterior)  distribution  that  can 
be  used  to  support  analysis. 


When  there  is  no  credible  pre-existing  evidence,  the  priors  must  be  based  on  professional 
judgment.  For  example,  for  critical  system  use,  one  might  use  CQA  prior  values  that  repre¬ 
sent  the  worst  case  until  evidence  is  available  that  indicates  that  the  situation  is  less  grim. 
(Start  with  a  prior  belief  that  availability  =  0  for  a  service,  where  availability  is  the  probabil¬ 
ity  that  the  service  will  be  available  when  needed.  If  evidence  accumulates  that  the  service  is 
indeed  consistently  available  when  needed,  the  prior  belief  will  become  increasingly  irrele¬ 
vant,  and  the  estimated  value  for  availability  should  be  increased.) 


The  Bayesian  approach  to  dynamic  updates  of  CQAs  provides  several  advantages.  It 

•  Allows  both  predicted  and  field/test  data  to  be  combined  into  a  precise  and  convenient 
function  for  the  CQA. 

•  Makes  available  all  knowledge  of  CQA  values. 

•  Allows  easy  updates  to  the  knowledge  as  appropriate. 


However,  the  Bayesian  approach  assumes  independent  risk  factors  and  therefore  tends  to 
overestimate  risk  when  there  are  multiple  correlated  risk  factors.  In  addition,  the  dynamic 
nature  of  the  CQAs  and  possible  correlation  between  the  CQAs  can  make  it  difficult  to  vali¬ 
date  the  CQA  measurements.  To  further  complicate  matters,  to  evaluate  functional  CQAs, 
flow  executions  must  be  treated  as  statistically  independent  trials,  ignoring  potential  issues 
such  as  internal  system  state  and  data  stores.  Thus,  care  must  be  taken  to  ensure: 

•  Sufficiently  conservative  priors  are  assigned 

•  Sufficient  experience  is  gained  before  it  is  incorporated  into  the  posterior  distribution 

•  Each  QA  function  is  periodically  reevaluated  and  reinitialized  based  on  history  and  any 
knowledge  about  changes  to  the  distributed  system. 


This  Bayesian  approach  for  dynamically  updating  CQA  projections  appears  to  be  far  better 
than  the  alternatives,  given  that  complete  knowledge  of  current  and  future  system  state  is  not 
possible.  Mathematical  details  and  examples  of  this  approach  are  provided  in  [Walton  et  al. 
2002],  The  methods  described  here,  namely  the  functional  attribute  model  that  maps  service 
usage  into  attribute  values,  the  state  transition  model  for  evaluating  attributes,  and  the  Bayes¬ 
ian  methods  for  dynamic  attribute  updates,  constitute  a  framework  for  Computational  Quality 
Attribute  research.  Work  is  required  to  develop  attribute-specific  models  within  this  frame¬ 
work.  The  requirement  that  attributes  be  measurable  in  a  defined  metric  for  computational 
purposes  also  permits  human  understanding  and  analysis  not  otherwise  possible. 
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6  Flow  Management  Architectures 


As  noted  earlier,  Flow  Structures  and  Computational  Quality  Attributes  support  system  archi¬ 
tectures  that  carry  out  dynamic  flow  and  attribute  management  in  execution.  Flow  Manage¬ 
ment  Architectures  can  provide  design  and  implementation  frameworks  for  this  puipose,  as 
well  as  associated  engineering  processes  for  system  architecture  development.  We  envision 
an  evolving,  open  family  of  FMA  frameworks  for  architecture  development  both  in  the  small 
and  in  the  large. 


FMA  templates  in  the  small  can  define  topologies  and  functional  capabilities  that  satisfy 
quality  attributes  for  localized  flow  management.  For  example,  a  quality  attribute  could  re¬ 
quire  network  isolation  of  a  particular  class  of  flows  for  security  purposes.  Such  a  require¬ 
ment  often  exists  for  external  user  flows  that  access  enterprise  Web  sites.  The  FMA  template 
in  this  case  could  define  a  DMZ-based  topology  to  isolate  external  users  from  enterprise  net¬ 
works,  plus  functional  isolation  of  operational  and  developmental  Web  servers.  Administra¬ 
tive  flows  would  also  appear  in  the  relevant  FlowSet,  and  the  template  would  include  topo¬ 
logical  and  functional  capabilities  for  monitoring  and  controlling  Web  site  operation.  Note  in 
this  illustration  that  quality  attributes  involving  flow  isolation  are  imposed  by  the  executing 
enterprise  and  not  by  the  flow  originators.  It  is  invariably  the  case  that  the  network  services 
traversed  by  flows  implement  their  own  attributes  and  management  procedures  for  processing 
incoming  flows. 


FMA  templates  in  the  large  can  define  system-level  topologies  and  functional  capabilities  for 
managing  user-requested  flow  instantiations  and  reconciling  attribute  requirements  where 
possible  with  service  capabilities  in  real  time  operation.  Such  templates  can  accommodate 
traffic  projections,  geographic  factors,  communication  patterns,  and  a  host  of  other  factors 
that  drive  large-scale  network  design. 


FMA  frameworks  can  also  include  engineering  processes  for  mapping  FlowSet  specifications 
into  network  and  service  designs.  FlowSets  define  access  requirements  for  logical  connec¬ 
tivity  among  services  as  a  sufficient  network  topology,  as  well  as  functional  requirements  for 
the  services  themselves.  Quality  attributes  associated  with  FlowSets  impose  additional  re¬ 
quirements  and  constraints  on  network  design.  These  relationships  between  network  usage 
embodied  in  flows  and  attributes  and  network  design  embodied  in  connectivity  and  function¬ 
ality  provide  an  opportunity  to  develop  systematic  engineering  practices  for  network  devel¬ 
opment  and  validation. 
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7  Conclusion 


Identification  of  flow,  service,  and  quality  as  first-class  concepts  for  the  development  of 
large-scale,  network-centric  systems  is  important  for  achieving  unification  of  this  complex 
engineering  activity.  Theoretical  foundations  developed  in  this  research  can  prescribe  engi¬ 
neering  practices  that  will  improve  system  management,  acquisition,  analysis,  development, 
operation,  and  evolution.  The  following  observations  summarize  this  research  vision. 

•  FSQ  engineering  supports  complexity  reduction  and  survivability  improvement  in  devel¬ 
opment  and  operation  of  large-scale  network  systems  composed  of  any  mix  of  newly  de¬ 
veloped  and  COTS  components. 

•  FSQ  engineering  provides  systematic,  scale -free  semantic  structures  for  requirements, 
specification,  design,  verification,  and  implementation. 

•  FSQ  engineering  supports  seamless  decomposition  from  user  task  flow,  service,  and 
quality  attribute  requirements  to  flow,  service,  and  quality  attribute  implementations, 
with  intrinsic  traceability. 

•  User  flows  of  services  and  quality  attributes  permit  system  development  in  terms  of  user 
views  of  services,  as  opposed  to  strictly  functional  decomposition  or  object-based  com¬ 
position. 

•  Flow  Structures  are  deterministic  for  human  understanding  and  analysis,  despite  the 
asynchronism  of  network  behavior,  thus  enabling  compositional  methods  of  refinement, 
abstraction,  and  verification. 

•  Flow  Structures  reflect  the  realities  of  network-centric  systems  in  dealing  the  Uncertainty 
Factors,  to  support  enterprise  risk  management  and  system  survivability. 

•  Flow  Structures  support  definition  of  attack  and  intrusion  flows  for  assessing  system  vul¬ 
nerabilities  and  compromises,  as  a  basis  for  security  and  survivability  improvements. 

•  Computational  Quality  Attributes  reflect  the  realities  of  network-centric  systems,  in  as¬ 
sessing  and  reconciling  quality  requirements  and  capabilities  as  an  intrinsically  dynamic 
process. 

•  Computational  Quality  Attributes  provide  a  scale -free,  computational  usage -centric 
(rather  than  system-centric)  view  of  quality. 

•  Flow  Management  Architectures  provide  systematic  and  uniform  methods  for  managing 
user  flow  instantiation  and  quality  attribute  satisfaction  in  execution. 

•  Foundations  of  Flow  Structures  can  stimulate  research  on  representation  and  analysis  of 
flows  at  the  requirements  level  within  enterprises,  and  at  the  implementation  level  within 
system  architectures. 
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•  Foundations  of  Computational  Quality  Attributes  can  stimulate  research  in  modeling  and 
dynamic  evaluation  of  important  quality  attributes  and  metrics. 


FSQ  research  and  development  efforts  will  continue  to  explore  foundations  for  Flow  Struc¬ 
tures,  Computational  Quality  Attributes,  and  Flow  Management  Architectures.  Several  pa¬ 
pers  are  in  preparation  that  detail  the  mathematical  foundations  of  Flow  Structures  and  Com¬ 
putational  Quality  Attributes  [Pleszkoch  et  al.  2002,  Walton  et  al.  2002].  This  work  will 
provide  a  basis  for  engineering  practices  and  support  tools. 
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